From 9a3c37c89ef866477bf3fba128d883f27bdc47ae Mon Sep 17 00:00:00 2001 From: Steve Klabnik Date: Mon, 29 Aug 2016 17:26:46 -0400 Subject: [PATCH] tweak policies --- src/doc/policies.md | 110 +++++++++----------------------------------- 1 file changed, 23 insertions(+), 87 deletions(-) diff --git a/src/doc/policies.md b/src/doc/policies.md index c832f8936..f32db45f4 100644 --- a/src/doc/policies.md +++ b/src/doc/policies.md @@ -1,27 +1,19 @@ % Crates.io package policies -# Packages Policy for Crates.io - -In [a previous post to the Rust blog] -(http://blog.rust-lang.org/2014/11/20/Cargo.html), -we announced the preview launch of -[crates.io](http://crates.io/), giving the Rust community a -way to easily publish packages. After a few weeks of kicking the tires, and -hearing the most common questions people have about the registry, we wanted to -clarify the rationale behind some of the design decisions. We also wanted to -take the opportunity to be more explicit about the policies around package -ownership on crates.io. - In general, these policies are guidelines. Problems are often contextual, and exceptional circumstances sometimes require exceptional measures. We plan to -continue to clarify and expand these rules over time as new circumstances arise. +continue to clarify and expand these rules over time as new circumstances +arise. # Package Ownership -We have had, and will continue to have, a first-come, first-served policy on -crate names. Upon publishing a package, the publisher will be made owner of the -package on Crates.io. This follows the precedent of nearly all package -management ecosystems. +We have a first-come, first-served policy on crate names. Upon publishing a +package, the publisher will be made owner of the package on Crates.io. + +If someone wants to take over a package, and the previous owner agrees, the +existing maintainer can add them as an owner, and the new maintainer can remove +them. If necessary, the team may reach out to inactive maintainers and help +mediate the process of ownership transfer. # Removal @@ -29,46 +21,27 @@ Many questions are specialized instances of a more general form: “Under what circumstances can a package be removed from Crates.io?” The short version is that packages are first-come, first-served, and we won’t -attempt to get into policing what exactly makes a legitimate package. We will do -what the law requires us to do, and address flagrant violations of the Rust Code -of Conduct. - -# Squatting +attempt to get into policing what exactly makes a legitimate package. We will +do what the law requires us to do, and address flagrant violations of the Rust +Code of Conduct. -Nobody likes a “squatter”, but finding good rules that define squatting that can -be applied mechanically is notoriously difficult. If we require that the package -has at least some content in it, squatters will insert random content. If we -require regular updates, squatters will make sure to update regularly, and that -rule might apply over-zealously to packages that are relatively stable. +## Squatting +We do not have any policies to define 'squatting', and so will not hand over +ownership of a package for that reason. -A more case-by-case policy would be very hard to get right, and would almost -certainly result in bad mistakes and and regular controversies. -Instead, we are going to stick to a first-come, first-served system. If someone -wants to take over a package, and the previous owner agrees, the existing -maintainer can add them as an owner, and the new maintainer can remove them. If -necessary, the team may reach out to inactive maintainers and help mediate the -process of ownership transfer. We know that this means, in practice, that -certain desirable names will be taken early on, and that those early users may -not be using them in the most optimal way (whether they are claimed by squatters -or just low-quality packages). Other ecosystems have addressed this problem -through the use of more colorful names, and we think that this is actually a -feature, not a bug, of this system. We talk about this more below. - -# The Law +## The Law For issues such as DMCA violations, trademark and copyright infringement, -Crates.io will respect Mozilla Legal’s decisions with regards to content that is -hosted. +Crates.io will respect Mozilla Legal’s decisions with regards to content that +is hosted. -# Code of Conduct +## Code of Conduct -The Rust project has a [Code of Conduct] -(https://github.com/rust-lang/rust/wiki/Note-development-policy#conduct) -which governs appropriate conduct for the Rust community. In general, any -content on Crates.io that violates the Code of Conduct may be removed. There are -two important, related aspects: +The Rust project has a [Code of Conduct] which governs appropriate conduct for +the Rust community. In general, any content on Crates.io that violates the Code +of Conduct may be removed. There are two important, related aspects: - We will not be pro-actively monitoring the site for these kinds of violations, but relying on the community to draw them to our attention. @@ -76,41 +49,4 @@ two important, related aspects: cannot be directly answered in the hypothetical sense. All of the details must be taken into consideration in these kinds of situations. -We plan on adding ‘report’ functionality to alert the administrators that a -package may be in violation of some of these rules. - -# Namespacing - -In the first month with crates.io, a number of people have asked us aboutthe -possibility of introducing [namespaced packages] -(https://github.com/rust-lang/crates.io/issues/58). - -While namespaced packages allow multiple authors to use a single, generic name, -they add complexity to how packaged are referenced in Rust code and in human -communication about packages. At first glance, they allow multiple authors to -claim names like http, but that simply means that people will need to refer to -those packages as `wycats’ http or reem’s http`, offering little benefit over -package names like wycats-http or reem-http. - -When we looked at package ecosystems without namespacing, we found that people -tended to go with more creative names (like nokogiri instead of “tenderlove’s -libxml2”). These creative names tend to be short and memorable, in part because -of the lack of any hierarchy. They make it easier to communicate concisely and -unambiguously about packages. They create exciting brands. And we’ve seen the -success of several 10,000+ package ecosystems like NPM and RubyGems whose -communities are prospering within a single namespace. - -In short, we don’t think the Cargo ecosystem would be better off if Piston chose -a name like `bvssvni/game-engine` (allowing other users to choose -`wycats/game-engine`) instead of simply piston. - -Because namespaces are strictly more complicated in a number of ways,and because -they can be added compatibly in the future should they become necessary, we’re -going to stick with a single shared namespace. - -# Organizations & related packages - -One situation in which a namespace could be useful is when an organization -releases a number of related packages. We plan on expanding the ’tags’ feature -to indicate when multiple crates come from one organization. Details about this -plan will come at a later time. +[Code of Conduct]: https://www.rust-lang.org/conduct.html -- 2.30.2